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Remarks 

Claims 21-22, 24-30, 32-33, 41-50, 64-77, and 79 are pending in the present patent 
application. In order to clarify issues for appeal, Claims 51-63 have been canceled pursuant to 37 
CFR§1.U6, without prejudice or disclaimer ofthe subject matter. Reconsideration of the pending 
Claims and allowance is respectfully requested in view of the amendments to the Claims and the 
following comments. 

The 35 U.S.C §H»fa^ Clai m Rejections 

In the office action mailed May 31, 2006, Claims 21-22. 24-30, 32-33 41-50 64-77 and 79 
stand rejected pursuant to 35 U.S.C. §103(a) as being obvious in view ofthe combination of U.S. 
Patent No. 6,635,089 to Burkett et al. (hereinafter "Burkett") and U.S. Patent No. 6,418,446 to 
Lection et al. (hereinafter "Lection"). In addition, Claims 51-63 were rejected pursuant to 35 
U S C §103(a) as being obvious in view of the combination of Burkett and U.S. Patent No. 
6 658 625 to Allen (hereinafter "Allen"). Claims 51-63 have been canceled rendering the 
corresponding rejections moot. With regard to Claims 21-22, 24-30, 32-33 41-50 64-77 and 79, 
Applicant respectfully Inverses the corresponding rejections because the cited combinations ofthe 
art fail to teach, suggest, or disclose each and every Umitation ofthe claims, and thus zprima facie 
case of obviousness in view ofthe cited art cannot be maintained. 

r.inimR2l-2 ? ?4-m 32-33. and 71-75 

On page 17 of the final rejection mailed May 31. 2006, it was indicated that Burkett 
teaches that a DOM document was tailored or modeled on the input data. Applicant does not 
disagree However, Claim 21 does not describe such a limitation. To the contrary, Claim 21 
describes that data in each of the fields are limited to a data type that is ^-specified m a 
w in ^ slices Plication, not ore-specified in input data. Thus, Burkett teaches away from 
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the limitation described in Claim 21. In addition, Lection describes a format that is required 
for the source data structure (Col. 7 lines 64-66), and that the records representing any type of 
structured source information may be specified for use (Col. 9 lines 46-51). Accordingly, 
Lection does not pre-specify a data type in a business services application as described in Claim 
21, but rather specifies a datatype in a source data structure. 

In addition, for purposes of appeal, Applicant respectfully traverses that Burkett and/or 
Lection teach or suggest translation of request parameters to a format identified with the pre- 
specified data type that is pre-specified, not by the request parameters, but by a business 
services application as described in Claim 22, To the contrary, both Burkett and Lection simply 
describe that XML documents are converted to a DOM tree, not translated to a format identified 
with such a pre-specified data type. Similarly, neither Burkett nor Lection teach or suggest an 
attribute of the request that is translated to a format identified, not in the request, but in the pre- 
specified data type that is pre-specified in the business services application as described in 
Claims 25 and 30. Moreover, it is respectfully asserted that neither Burkett nor Lection teaches 
or suggests selection of a mode debug flag as described in Claim 26. To the contrary, neither 
Burkett nor Lection mention any kind of selectable flag, and especially not a flag related to the 
length of field names as described in Claim 26. Also, neither Burkett nor Lection teach or 
suggest chat a static declaration of a datatype is loaded based on a list of fields expected in a 
request as described in Claim 28. Instead, both Burkett and Lection rely on the request to 
dictate the datatype and are completely silent on any list of what fields are expected. Nor do 
Burkett or Lection teach or suggest that a form of data is converted based on the pre-specified 
data type as described in Claim 29. 

Claims 41-50, 76-77. and 79 

On page 18 of the office action mailed May 31, 2006 it was asserted that the same basis for 
rejection of Claim 21 applies to Claim 41. Applicant respectfully emphasizes that Claim 41 
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describes a class operable on a server that includes a listing of pre-specified fields each of which 
describe a corresponding pre-specified data type to which the format of corresponding fields 
included in an input message are limited. Claim 41 clearly describes data types that are ore- 
specified in a class operable o n a server , not data types included in source information (such as an 
XML document) being converted to a DOM tree as described in Lection (Col. 9 lines 52-60), and 
Burkett (Col. 2 lines 44-48). Claim 41 also describes executable custom application code , not 
source information, that includes a pre-specified data type to limit the format of fields included in 
an input message that do not correspond to the listing of pre-specified fields included in the 
MESSAGEDEFINITION class. Clearly, neither Burkett nor Lection even mention a class and 
executable custom application code that each include pre-specified data types. Accordingly, 
neither Burkett nor Lection can possibly describe a listing of pre-specified fields used to limit a 
format of corresponding fields in an input message, and another pre-specified data type to limit the 
format of fields in the input message that do not correspond to the listing. As previously 
discussed, both Burkett and Lection are simply using the information provided from a data source, 
and thus allow the information being converted to a DOM to dictate the format of the DOM. 

Also, for purposes of appeal, none of the cited art teaches a pre-specified data type 
included in executable custom code that is operable to limit a format of fields included in an 
output message as described in Claim 42. In addition, the cited art does not teach or suggest a 
mode debug flag as described in Claim 46, and as previously discussed, or that a short and a long 
field name selectable with the mode debug flag are defined in the MESSAGEDEFINITION class 
as described in Claim 47. 



Claims 64-70 

Applicant respectfully emphasizes that Claim 64 describes a server computer operable to 
execute instructions to restrict the conversion of a document object model based on a listing of 
datatypes that are pre-specified for the request parameters. On page 20 of the office action 
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mailed May 31, 2006, it was asserted that a listing of datatypes was obtained via the inherent 
parsing and subsequent tree structure construction performed via DOM processing. However, 
Applicant respectfully asserts that a pre-specified listing cannot be one that is obtained via DOM 
processing. To the contrary something which is pre-specified by its very nature must have been 
specified previously. Even if a listing is generated during DOM processing, it clearly cannot be 
a pre-specified listing since such a list was not specified prior to DOM parsing. 

In addition, Burkett specifically describes a DOM tree is constructed based on the syntax 
of tags embedded in a file. (Col, 2 lines 44-47) Nowhere does Burkett make clear that a pre- 
specified listing is necessarily present and/or generated. Inherency may not be established by 
probabilities or possibilities, and the mere feet that a certain thing may result from a given set of 
circumstances is not sufficient. (See MPEP §2112 (IV) ) In addition, the Examiner must 
provide a basis in fact, and/or technical reasoning to support such a determination. MPEP 
§2112 (IV). Applicant respectfully asserts that neither Burkett, Lection, nor the Examiner have 
provided sufficient evidence that a pre-specified listing is obtained during DOM processing. 
Thus, a rejection based on such unfounded conjecture cannot stand. 

For at least the foregoing reasons, the combination of Burkett and Lection fail to fulfill 
the third basic criteria for obviousness that must be met, which is that all the limitations of the 
claims must be taught or suggested by the combination of the cited prior art. Since all of the 
claim limitations described by Claims 21, 41 and 64 and the Claims dependent therefrom are not 
taught or suggested, a prima facie case of obviousness cannot be maintained. Applicant 
respectfully requests withdrawal of the 35 U.S.C. §103(a) rejection of Claims 21-22, 24-30, 32- 
33, 41-50, 64-77, and 79. 

Conclusion 

In view of the amendments to the Claims and the above discussion, the application is 
believed to now be in condition for allowance, which is respectfully requested. Should the 
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Examiner deem a telephone conference to be beneficial in expediting examination and/or 
allowance of this application, the Examiner is invited to call the undersigned attorney at the 
telephone number listed below. 




Respectfully submitted, 



SNH/sev 



BRINKS HOFER GILSON & LIONE 
Customer No. 33391 
Telephone: 317-636-0886 



QZ/QZ 39Vd 
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